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The NASA Engineering (NE) Directorate at Kennedy Space Center provides engineering 
services to major programs such as: Space Shuttle, International Space Station, and the 
Launch Services Program (LSP). The Avionics Division within NE, provides avionics and 
flight control systems engineering support to LSP. The Launch Services Program is 
responsible for procuring safe and reliable services for transporting critical, one of a kind, 
NASA payloads into orbit. As a result, engineers must monitor critical flight events during 
countdown and launch to assess anomalous behavior or any unexpected occurrence. The 
goal of this project is to take a tailored Systems Engineering approach to design, develop, 
and test Iris telemetry displays. The Flight Avionics Sequencing Telemetry Delta-IV (FAST- 
04) displays will provide NASA with an improved flight event monitoring tool to evaluate 
launch vehicle health and performance during system-level ground testing and flight. Flight 
events monitored will include data from the Redundant Inertial Flight Control Assembly 
(RIFCA) flight computer and launch vehicle command feedback data. When a flight event 
occurs, the flight event is illuminated on the display. This will enable NASA Engineers to 
monitor critical flight events on the day of launch. Completion of this project requires 
rudimentary knowledge of launch vehicle Guidance, Navigation, and Control (GN&C) 
systems, telemetry, and console operation. Work locations for the project include the 
engineering office, NASA telemetry laboratory, and Delta launch sites. 


Nomenclature 


CARDS 

= 

Computer Aided Render Display 

NASA 

= 

National Aeronautics and Space 



System 



Administration 

CCAFB 

= 

Cape Canaveral Air Force Base 

NE 

= 

NASA Engineering 

CDR 

= 

Critical Design Review 

PCM 

= 

Pulse Code Modulation 

CONORS 

= 

Concept of Operation 

PDR 

= 

Preliminary Design Review 

DCR 

= 

Design Certification Review 

PM 

= 

Project Manager 

DTPS 

= 

Delta Launch Processing System 

RAM 

= 

Random Access Memory 

DOC 

= 

Delta Operations Center 

RIFCA 

= 

Redundant Inertial Flight Control 

DOD 

= 

Department of Defense 



Assembly 

ELV 

= 

Expendable Launch Vehicle(s) 

SE 

= 

Systems Engineering 

FAST-D4 

= 

Flight Avionics Sequencing Telemetry 

SRR 

= 

System Requirement Review 



Delta IV 

TDP 

= 

Telemetry Data Processing 

FF 

= 

Functional Flow 

TPM 

= 

Technical Performance Measurement 

HOQ 

= 

House of Quality 

ULA 

= 

United Launch Alliance 

KSC 

= 

Kennedy Space Center 

USRP 

= 

Undergraduate Student Research 

LCC 

= 

Launch Control Center 



Project 

LSP 

= 

Launch Services Program 

V&V 

= 

Validation and Verification 

MSID 

= 

Measurement Identification 





I. Introduction 

T he National Aeronautics and Space Administration (NASA) has been a space exploration leader since 1958 in 
three core competencies: research and technology, flight hardware and development, and mission operations. 
The NASA Engineering (NE) branches servicing the Launch Services Program (LSP) contributes to the third 
competency of NASA by procuring safe and reliable services for transporting critical, one of a kind, NASA 
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payloads into orbit. To provide this reliability, engineers must monitor critical flight events during launch to assess 
any anomalous behavior or unexpected occurrence. One of the launch vehicles used by NASA is the Delta IV rocket 
built by United Launch Alliance (ULA). Part of NASA Engineering’s responsibility is to evaluate vehicle health and 
performance during system level pad testing and flight. To assist NASA engineers in reviewing vehicle data, a new 
tool was developed to display flight events for the Delta IV launch vehicle. This project develops the Flight 
Avionics Sequencing Telemetry-Delta IV (FAST-D4) display which is a new telemetry display based on Iris. FAST- 
04 provides the NE Expendable Launch Vehicle (ELV) Avionics branch with an independent assessment tool to 
evaluate health and performance of the Delta IV launch vehicle. This tool functions by illuminating flight events on 
a display to alert the user that a command has been sent by the flight computer. FAST-D4 utilizes pre-existing 
telemetry hardware at Hangar AE and easily interfaces with the Iris and Winplot data display systems. The contents 
of this paper describe the design and development of the FAST-D4 display with a tailored Systems Engineering (SE) 
approach. 


II. NASA Engineering’s Role in the Launch Services Program 

The Launch Services Program Office is located at the Kennedy Space Center (KSC) and is responsible for the 
vehicle selection and management of expendable launch vehicle missions. The principal objectives are to provide 
safe, reliable, cost-effective, and on-schedule processing. LSP also provides mission analysis, spacecraft integration, 
and launch services for NASA and NASA-sponsored payloads needing a mission on an ELV. LSP is responsible for 
the success of its missions and implements a technical oversight approach to ensure the reliability of each vehicle. 
Unlike commercial companies, NASA does not buy insurance for their spacecraft; instead, the LSP program ensures 
mission success by mitigating risk. 

LSP acquires avionics and flight control systems engineering services from the NE directorate. These services 
include clarifying the technical objectives required for each mission and reviewing flight hardware, which includes 
analyzing the design and development of new implementations. The branch also provides technical oversight during 
integrated launch vehicle checkout and console support during day of launch activities. The fleet of launch vehicles 
that NE oversees includes the Delta, Atlas, Taurus, and Pegasus vehicles (Fig. 1). 

A 


FS 


Figurel. The NASA LSP Fleet (from the left: Delta IV, Atlas V 500 Series, Atlas 
V 400 Series, Delta II, Taurus, and Pegasus). 




III. Problem Statement and Solution 

NASA Engineering needs a telemetry display for the Delta IV launch vehicle to capture short duration 
sequencing events such as 1 80ms ordnance events. NASA Engineering requires a display to aid in monitoring the 
vehicle’s health. The design needs to be compatible with existing telemetry architecture to reduce cost, and the 
formatting needs to be similar to previous architectures to facilitate the user’s navigation of the page. . Since 
ordnance events are too quick for the existing telemetry display, a latch needs to be included on the display that will 
keep the flight event illuminated until the user issues a reset command. The latch will keep the flight event 
illuminated until the user issues a reset command. Each page should also show a quick view of the 1 st or 2 nd stages to 
keep the engineer informed of flight events from both stages at all times. The final product should provide NASA 
Engineering with a useful tool for viewing Delta IV flight event telemetry. 
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IV. Systems Engineering Approach 

A tailored Systems Engineering (SE) approach (Fig. 2) is applied to the organizational structure of this project to 
ensure the quality of the final product. The process begins with soliciting the stakeholder’s needs. Stakeholders are 
individuals or groups that have an interest in or need for the final project. Once the stakeholders’ needs have been 
identified, a timeline (Fig. 3) is created to establish critical SE milestones. Next, two diagrams are produced to 
provide the basis for developing the system level requirements and to clarify the technical processes involved. The 
first diagram is the Functional Flow (FF) which is a flow diagram that describes in words the technical steps that 
occur in the final product. The second diagram is the Concept of Operation (CONOPS) which provides a pictorial 
representation of how the final product will function within the system. Afterwards, a System Requirement Review 
(SRR) is conducted to baseline the system level requirements with the stakeholders. Next, a preliminary design or 
prototype is developed and data collection begins. The next step develops the design-lo requirements which describe 
how the system level requirements will be implemented. After all requirements have been defined, the design team 
holds a Preliminary Design Review (PDR) to baseline the design- to requirements and ensure that the project is on 
schedule, the technical performance meets the stakeholders standards, and the prototype meets system level 
requirements. Once the PDR is accepted by the stakeholders, the product begins development. The development 
process iterates many cycles of prototype production and Validation and Verification (V&V) processes which 
confirm that the right product was produced, the stakeholders’ needs were met, and that it was built according to the 
system level and design-to requirements. Then, a Critical Design Review (CDR) is conducted to verify with the 
stakeholders that the product is mature enough for finalization. Once the stakeholders approve the CDR, the project 
is finalized and the V&V process is completed. Finally, the Design Certification Review (DCR) certifies the design 
for release. 



Figure 2. Tailored Top-Down/ Bottom-Up Systems Engineering Development Process 
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Figure 3. Project Timeline 


V. Stakeholders Needs 

The Stakeholders are identified according to their influence in Fig. 4. Stakeholders for this project include 
NASA, the Engineering directorate, LSP, the design team, ULA, and Hangar AE. The stakeholders’ needs are 
assessed through meetings, interviews, or direct requests. Many of these stakeholders are involved in the SRR, 
PDR, CDR, and DCR Systems Engineering processes to discuss their needs with the design team. Tablet defines 
the needs of the stakeholders for the FAST-D4 display. 



Figure 4. FAST-D4 Proiect Stakeholders 
Table 1. Stakeholder Requirements 


No. 

Stakeholder Requirements 

1 The stakeholder needs a toolbox to display telemetry to illustrate flight events for Delta IV. 

II 

The stakeholder needs the toolbox to be compatible with existing telemetry architectures. 

III 

The stakeholder needs the toolbox to be easy to use. 
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VI. Case Study 

An important part of the SE process is to identify which method would be the best approach to execute the 
project. OpenOffice and Microsoft Power Point were studied to assess the pros and cons of using either software. 
Power Point offered some convenient tools for creating a telemetry display. First, Power Point can be easily 
converted into a web page which enables the engineering team to view how the final design would look at Hangar 
AE. Power Point also automatically adjusts the display size to fit the console monitor where it is being viewed. It is 
also easy to insert clip art and manipulate the size of the widgets. However, the FAST-D4 telemetry display requires 
a very large number of telemetry signals that would require a great amount of time to insert into Power Point and be 
difficult to organize. OpenOffice offered a better solution to that issue since existing cells allow data to be inserted 
more easily. OpenOffice also has a hiding feature that allows informative data such as the Measurement 
Identification (MSID), description, and raw signal to be accessible yet not displayed. This is important, because 
space is limited for flight events on the consol. Hangar AE can use either software program; however, the case study 
concluded that OpenOffice provides the best approach to implementing a telemetry display with such a large 
number of parameters. 


VTI. Project Management Hierarchy 

The Project Management Hierarchy is a part of the SE process that defines where all contributors of the project 
stand within the internal structure. Figure 5 indicates the hierarchy for the FAST-D4 display. All members of the 
structure work together, and some participate in multiple areas. The project manager oversees the implementation of 
the design and is responsible for the success of the project. The Systems Engineers assist in the application of proper 
systems engineering techniques to ensure the quality of the final product. Hangar AE provides technical support 
regarding pre-existing telemetry systems. Avionics Engineers provide flight controls and operational support 
necessary for successful completion of the design. 



Figure 5. FAST-D4 Project Management Hierarchy 


VIII. Concept of Operation 

The CONOPS for the FAST-D4 display are shown in Fig. 6 and 7. Figure 6 shows the CONOPS for the 
telemetry system as a whole, and Figure 7 shows the CONOPS for the telemetry processing inside Hangar AE that 
directly relates to FAST-D4. When the launch vehicle is powered on, telemetry data is sent directly to the Launch 
Control Center (LCC) by hard line. At approximately T - 6 minutes the launch vehicle begins transmitting 
telemetry by radio frequency through S band. The S band telemetry goes through a system of downrange 
telemetry assets and eventually is relayed to Hangar AE. Inside Hangar AE the patch panel receives the telemetry 
and routes it to the Telemetry Data Processing (TDP) unit. The TDP handles real-time front end processing of 
Pulse Code Modulation (PCM) streams. It consists of a bit synchronizer and PCM decommutator. From the TDP, 
the telemetry is sent to Scramnet which is the Random Access Memory (RAM) for two computers; CARDS and 
Frame Capture. The telemetry takes two separate paths at this point to be distributed to two separate programs. 
The Frame Capture computer captures PCM frames into files for storage and then sends the frames to Winplot 
Archiver. Winplot Archiver stores every sample and then sends the stream to Winplot. Winplot, a software strip- 
charting tool, receives all samples used for real-time and post-test analysis. Unlike Frame Capture, the CARDS 
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computer does not store every sample; instead, it collects data into packets for the Iris telemetry program. The Iris 
hardware and software de-couples raw telemetry and graphically displays all measurements. It is designed to be 
scalable and easily deployable to different locations depending on the location of the launch. FAST-D4 detects 
flight events by looking at changes in the discrete telemetry from Iris. 



Launch Control Center Hangar AE Console in Hangar AE 


Figure . FAST-D4 Concept of Operations of Existing Architectures 



Timinj 




Winplot 


FAST-D4 Display 


Figure 7. FAST-D4 Concept of Operations inside Hangar AE 


IX. Functional Flow 


The Functional Flow (FF) shown in Fig. 6 provides a flow chart of how the actual product will function. 
FAST-D4 begins with the Launch Vehicle (LV) broadcasting telemetry (TLM) and ends with the flight event being 
illuminated on the screen. 



Flight event is 
illuminated 


Figure 8. FAST-D4 Functional Flow Logic in Each Cell 
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X. Prototype 

A prototype provides a visual sample of how the final project will work or how it will look. The first prototype 
shown in Fig. 9 looks very different from the final project, but many of the same concepts are implemented. This 
prototype labels daily events, and illuminates a green box when an event occurs. For example, the bit designated for 
waking up was activated, so the corresponding box is illuminated. The second prototype in figure 10 appears much 
more like the final product, but contains very different functional logic. 



Charlotte's Daily Events{no Macros) 

Evt# 

MS1D 

Alt Name 

Description Value 

Units 

Green Box 

Time Stamp 

Value 

Binary 

1 

abcl 

wkup 

Wake up 

snooze buttons 

1 

6:00am 

1 

0000000000000001 

2 

def2 

brkfst 

Eat Breakfast 

cheerios 

1 

6:16am 

2 

0000000000000010 

3 

geh3 

gtrdy 

Get ready for work 

activities 

1 

6:30am 

4 

0000000000000100 

4 

ijk4 

dv2wk 

Drive to work 

turns 

1 

7:15am 

8 

0000000000001000 

5 

Imn5 

shwbdg 

Show Badge 

slowing rate 

0 

7:45am 

16 

0000000000010000 


Figure 9. Prototype 1: Charlotte’s Daily Events 



Figure 10. A) Prototype 2: CBC Display Figure 10. B) Prototype 2: Upper Stage Display 


XI. The System Level Requirements 

Once the stakeholders needs have been identified and a case study has been performed, the system level 
requirements are determined. The system level requirements define the system architecture that must be 
implemented to meet the stakeholders’ needs. For instance, the stakeholder needs the telemetry display to be 
compatible with existing architecture. One system level requirement is met by using OpenOffice since it interfaces 
easily to Iris as determined by the case study. The system level requirements for the FAST-D4 display are listed in 
Table 2 below. 


Table 2. System Level Requirements 


No. 

System Level Requirements 

I.A 

The display shall contain all flight critical data. 

I.B 

Both displays shall illuminate flight events as received. 

I.C 

Both displays shall contain a resettable latching mechanism to capture ordnance events 

II. A 

The toolbox shall be compatible with the Iris Telemetry System. 

II. B 

The toolbox shall be compatible with Winplot. 

n.c 

The toolbox shall read the telemetry from the Launch Vehicle. 

III. A 

All display functions shall be easy to navigate 

III.B 

The toolbox shall follow a standard color scheme for the text and signals 


XII. Design-to Requirements 

The design-to requirements specify the desired outputs of the system. The Concept of Operation, Functional 
Analysis, and System Level Requirements form the basis for these specifications. For example, the system level 
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requirement that the display shall contain all flight critical data will be implemented by displaying the true and 
complimentary flight parameters for system 1 and system 2. 


Table 3. Sample of Design-to Requirements 


No. 

Design-to Requirements 

I.A.l 

Both displays shall list true and complimentary flight parameters for system 1 and system 2. 

I.A.2 

Both displays shall contain the MSID for each telemetry signal. 

I.A.3 

Both displays shall contain the IRIS description for each telemetry signal. 

I.A.4 

Both displays shall be compatible with East and West coast NASA telemetry labs. 

I.A.5 

Both displays shall contain RIFCA telemetry data. 

I.A.6 

The Upper Stage display shall contain a quick view of the CBC display. 

I.A.7 

The Upper Stage display shall contain 2nd stage flight events. 


XIII. Implementation 

Implementation of the FAST-D4 display consisted of various design methods including data collection, 
problem solving, programming, and communication systems analysis. During the implementation phase of the 
systems engineering process, three iterations of the FAST-D4 display were produced, tested, and revised to meet 
the stakeholders’ requirements. Peer reviews, code analyses, and system testing were used to satisfy design 
solutions and verify specified requirements. 

Prior to the implementation of the FAST-D4 display, a spreadsheet requiring programming skills similar to 
those needed for the second prototype was produced. This initial prototype listed the system engineer’s daily 
events such as waking up and included examples of data such as MSID, alternate name, and description. Each 
event was coupled to a grey indicator box that would illuminate green when the event occurred. These events, like 
flight events, are assigned to bits in specific words which make up the frames used for telemetry. The illumination 
criterion was the presence of a binary ‘1’ or ‘bit’ from a specified location within a 16-bit word. Since the inputs 
to the display were in decimal representation, the first step to implement this requirement was to convert the 
decimal input to binary. Excel comes with a binary to decimal converter function; however, it was discovered that 
this function only works for binary words less than or equal to 9 bits. Therefore, a macro was written to replace 
this function. The macro accomplished this task; however, to create a design comparison, an alternative method 
was investigated. The alternative method used a combination of different functions embedded in the spreadsheet 
that also successfully completed the conversion. Once the conversion was completed, a bit search function was 
utilized to locate the set bit or event trigger, and the cells were illuminated using conditional formatting. The 
spreadsheet passed all testing, and the design team was then ready to implement the FAST-D4 display. 

The second prototype began with one page intended to contain all flight event data. The page contained 
visible cells designated for illumination of flight events and hidden cells containing parameter names, MSID’s, 
description, Engineering Units (EU), and raw data for analysis. Each flight event contained two sets of data to 
provide system redundancy. This included system 1 HIGH, system 1 LOW, system 2 HIGH, and system 2 LOW 
parameters. Most of the MSID’s were found in the ULA Delta IV Vehicle Assembly Launch Test Requirements 
document using the parameter name. The description, EU data, and raw data were then easily found by looking up 
the MSID in Iris. The remaining parameters were not found in this document, because they were latching 
parameters derived from ordnance events. Since ordnance events are often only 180ms long, these latching 
parameters illuminate when triggered by an ordnance event and stay on until the user turns them off. The latching 
mechanism requires formulas embedded in the spreadsheet to capture the trigger, and a macro to enable the latch. 
The ordnance event parameter names and corresponding MSID’s were retrieved from a parameter file. The 
ordnance event MSID’s were then used in Iris to look up their corresponding description, EU data, and raw data 
telemetry. The latch was created using two buttons titled ‘set’ and ‘reset’ in OpenOffice that contained two 
separate macros. A ‘1’ was inserted into a hidden cell if ‘set’ was selected, and a ‘0’ was inserted if ‘reset’ was 
selected. The next step was to add an additional column in the spreadsheet for latching parameters and insert 
embedded formulas to capture ordnance events. The embedded formulas required variables from the latch value, 
the discrete ordnance data, and the previous value of the formula. Since the formula required the cell to be 
referenced to itself, the output returned an error even after many data manipulations. OpenOffice was not storing 
the previous value of the cell, so the design team attempted to insert the formula into a macro. This solution was 
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undesirable, because the macro could not process the inputs efficiently and would consistently freeze the 
application. It was concluded that the macro would not be stable enough for operation at Hangar AE, and the 
focus was then turned back to embedded formulas. Additional research was done on OpenOffice, and the design 
team found that the iterations option which allows a cell’s previous value to be stored in the memory was disabled 
unless activated by the user. The iterations option was then enabled and the latching function worked nominally. 
After the technical issues were solved, conditional formatting for cell illumination and page layout were designed 
for usability and general aesthetics. Due to the number of events being captured and displayed, it was decided to 
split the screen into two pages for clarity and ease of use. Finally, testing was done at Hangar AE by running a 
playback of a previous Delta IV launch countdown. The non-ordnance flight events were illuminating nominally; 
however, several ordnance events were not triggering the latch. Also, the display size was too small for the 
console and needed to be enlarged. 

Prototype three began with an ordnance event analysis using Winplot. Since the Winplot software displays 
full rate data from the launch vehicle, the ordnance events were verified in graphical format. The Winplot diagram 
revealed that the latch trigger did not function properly. This meant that there was an issue with how OpenOffice 
was retrieving data from Iris. The problem was that OpenOffice only updates raw or EU data from Iris once every 
second, and Iris only refreshes data every half-second. The Hangar AE team solved this problem by suggesting 
the cells be referenced to a monitor program associated with Iris instead of raw data. This monitor program 
evaluates high, low, and present- time values every half second from CARDS. The Iris monitor program detects 
flight events by evaluating changes in these outputs. For example, if the 180 ms ordnance event does not occur 
when the present time sample is taken, the high value would still be triggered and indicate that an ordnance event 
occurred. Some formulas had to be altered slightly to accommodate this change. Unlike raw data, data from the 
monitor file returned values other than ‘1’ if a flight event occurred. A function was created to convert these 
values to a ‘1’ if the ordnance event was triggered and a ‘0’ if it was not. The latching cell was then referenced to 
the function to complete the technical troubleshooting. Next, the display size was adjusted to fit the console, and 
the font was enlarged to increase visibility. The display was tested again using the same playback data from the 
recorded launch. The project manager and design team concluded that the product was ready to be finalized. 

Senior NASA Avionics Engineers reviewed the product in a Design Certification Review (DCR) and agreed 
that the product was mature enough for certification. The stakeholders’ needs were met for a product that is easy 
to use, compatible with existing architectures, and monitors flight event telemetry for the Delta IV launch vehicle. 
FAST-D4 will be used in the upcoming Delta IV launch scheduled for September 2010 and will be tailored to 
other existing NASA fleet vehicles. 

XIV. Verification and Validation 

Verification and Validation (V&V) is a SE process that verifies that the right product was produced and 
validates that it was produced correctly. This process was completed at Hangar AE for prototypes 2 and 3 by 
running a playback of the GPS2F1 Delta launch. The V&V matrix shown in table 4 below indicates the 
specifications for each design-to requirement involving the second and final prototype. The first prototype is not 
included, because the design-to requirements do not match all of the design-to requirements of the final product. 
In this table, the first design-to requirement for testing all four parameters for each flight event was done July 23 
and 30, 2010 by the Systems Engineer, Hangar AE, and Project Manager (PM) as an inspection and test. This 
concludes that the stakeholders’ need was met appropriately and effectively. 



V&V Matrix 

V&V Method Auditor 

Dates 

Level 

Requirement 

I A T D SE PM AE 

Prototype 2 

Prototype 3 

LA.1 

Both displays shall list true and complimentary flight parameters for system l and system 2. 

y s y/ 

7/23/2010 

7/30/2010 

I.A 2 

Both displays shatl contain the MSID for each telemetry signal. 

y Y 

7/23/2010 

7/30/2010 

IA. 3 

Both displays shall contain the IRIS description for each telemetry signal. 

y 1 y 

7/23/2010 

7/302010 

I.A.4 

Both displays shatl be compatible with East and West coast NASA telemetry tabs. 

v / vss 

7/23,2010 

7/30-2010 


Table 4. Sample Validation and Verification Matrix 


XV. Final Product 

FAST-D4 was approved for certification August 10, 2010. The final product is shown in Fig. 1 1 A and B below. 
The flight events properly illuminate when the appropriate signal is received from Iris, and the display is the correct 
size for the monitors at Hangar AE. 
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XVI. Maintainability 

Each NASA mission is unique; thus, for each mission, the sequence or presence of certain flight events may 
change. The FAST-D4 telemetry display was designed with this in mind and can be easily adjusted to accommodate 
new requirements. The spare flight event cells are ready to be used if required for the mission. The only 
implementation that would be needed is to insert the telemetry parameter for the new flight event, and determine the 
output value that would indicate that the flight event has occurred. 

NASA Engineering routinely acquires ULA launch services for several vehicles other than Delta IV. The FAST- 
04 display also provides a versatile foundation for creating new displays for other vehicles. All architectures within 
the display can also be adjusted at the user’s discretion; this includes parameters, size, color, functions, macros, etc. 
This maintenance will ensure that the display is up to date and accurate for future missions. 


XVII. Future Implementation 

NASA Engineering constantly looks for new ways to improve existing capabilities. FAST-D4 is a new capability 
that has flexibility to allow for future enhancement, including quick access to Winplot, a time stamping tool, and a 
tool to locate flight events with a cursor in a flight sequence document. 

A tool that provides quick access to Winplot would be beneficial to NE and the Hangar AE team. 
Implementation of this tool could be accomplished by creating a button with a macro that takes the user directly to 
the strip-charting tool. Since the display would allow direct access to Winplot, the user would save time and be able 
to verify flight events more accurately. 

A time stamp would also be beneficial, because it would allow engineers to see exactly when a flight event 
occurred. This is important in launch vehicle diagnostics for determining the cause of any anomalous system 
behavior. Right now, Winplot is used as the primary tool for determining the time of flight events relative to 
important events. Although Winplot is very accurate, the flight event would have to be located in order to determine 
the time. This task is not too difficult, but a time stamp would provide a convenience to the engineer, so that they 
can focus on more critical objectives. 

Engineers use a flight event sequence document to verify vehicle flight events. It can sometimes be difficult to 
track the flight events in this document since so many critical events are taking place. Some engineers have 
expressed interest in a tool that would display an arrow next to the flight event that is occurring in the document. 
This would facilitate the launch monitoring process. 

These three implementations would contribute greatly to the FAST-D4 display by providing conveniences to the 
engineer. Quick access to Winplot, a time stamp, and a cursor following flight events would not be difficult to 
implement, however, they require a significant amount of time. Time constraints prevented the implementation of 
these features on the baseline release. 


XVIII. Conclusion 

NASA Engineering provided leadership, management, and flight expertise services to successfully implement 
the FAST-D4 display. By utilizing a systems engineering approach, I helped develop a product that met all 
stakeholder requirements: display flight events, use existing architectures, and implement a user friendly interface. 
FAST-D4 contains all flight critical events that illuminate correctly when the telemetry signal is received from Iris. 
The latch implementation also resulted in success by accurately capturing ordnance events under 180 ms. Senior 
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NASA Avionics Engineers have examined the display and certified the design for release. This product will be used 
for processing the upcoming Delta IV launch in September to assist engineers in monitoring the system for any 
anomalous behavior. 
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Appendix 

Table 5. FAST-D4 Display Requirements 
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I.A.8.iii The quick view shall contain 2nd stage discrete word 2 data RIFCA telemetry. 

I.A.8.iv The quick view shall contain 2nd stage CNTL/GJ discrete word data RIFCA telemetry. 

I.A.8.V The quick view shall contain second stage discrete word 3 data RIFCA telemetry. 

I.A.8.vi The quick view shall contain MTU antenna format word data RIFCA telemetry. 

I.A.9 The CBC display shall contain first 1st stage flight events. 
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USRP Internship Experience 

I am an Electrical Engineering student working as a NASA intern at KSC this summer, and will be entering my 
senior year at Arkansas Tech University this fall. During this internship, I had the opportunity to work for the NE 
Avionics branch through the USRP program which provided me with a broad range of activities. I was provided 
with an excellent introduction into researching and analyzing engineering issues. Through this experience I acquired 
a great amount of knowledge in launch vehicles avionics/GN&C, programming, SE techniques, and telemetry. I was 
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